Как же правильно отобразить иерархию с помощью дерева? Чтобы было понятно? Ведь в структуре подчиненности могут быть циклы.
Мой ответ - никак! Так что же делать? Ответ прост - нужно отображать не ДЕРЕВОМ, а ГРАФОМ!
Как же в 1с отобразить графом? Стандартно никак, но можно ведь немного извернутся, и все получится.
Новая версия - увеличена скорость! Сейчас стрелки в нужном направлении.
Добавлена версия под 8.2.
Скачать файл
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Механизм «Динамическое управление доступом к элементам форм объектов 1С8» предназначен для обеспечения возможности оперативного управления видимостью и доступностью элементов форм документов и справочников продуктов фирмы «1С» «1С:Предприятие 8».
Решение универсальное, встраивается в любую конфигурацию с минимальными доработками, что позволяет без проблем обновлять типовые решения.
Богатый редактор картинок 1С предназначен для обработки изображений в режиме «Предприятие», с возможностью РИСОВАТЬ на них. Поддерживается работа как в обычных формах (толстый клиент) так и на управляемых формах (тонкий клиент). Обработка позволяет редактировать как картинки, хранимые в базе, так и графические файлы с диска на файловой системе. Помимо базовых функций (изменение размеров, преобразование формата, обрезание картинки, повороты и т.п.) – редактор имеет богатый набор инструментов для рисования. Доступна функция вставки изображения из буфера обмена. Объект может быть использован: на стороне клиента, на стороне сервера, из внешнего соединения. Обработка будет особенно полезна тем, кто вносит картинки в базу (изображения номенклатуры, фотографии физических лиц и т.п.). Функционал реализуется с использованием JavaScript и бесплатного ПО ImageMagick (без использования внешних компонент).
Редактор графов в 1С - внешний отчет, который формирует графы на основе таблицы значений, используя рисунки табличного документа. Есть возможность добавления, редактирования объектов графа и выгрузки результата в таблицу значений.
Это инструкция по дизайну форм в среде 1С. Гайд охватывает рекомендации и стандарты для оптимизации пользовательского интерфейса. В гайде содержатся указания по использованию элементов интерфейса, включая как основные, так и продвинутые аспекты. Предоставляются также примеры и антипримеры для наглядного понимания принципов дизайна
Замерил производительность 14 секунд (второй запуск обработки) и менее секунды типовая. Мдассссссссссссс запустил третий раз и не подумав флаги поставил (искать мол в шапке таб частях) . Конфу закрывал через диспетчер
+(50) (7) - учитывая графический результат и направления стрелок - представленный продукт правильнее было бы назвать "Граф ссылок на объект", а никак не "Структура подчиненности"
Добавлял эти флажки специально для типовых решений. Там очень большой граф может получиться, так как есть некоторые типы документов наподобие расчета НДС, которые содержат в табличной части, документы реализаций.
А вот насчет производительности не понятно, я мерил у меня формируется очень быстро.
Да а зачем через диспетчер закрывали, неужто ctrl+break не помог? В коде прерывание пользователя прописано.
{Форма.Форма(137)}: Ошибка при вызове метода контекста (Выполнить): Ошибка выполнения запроса "Построенный запрос к СУБД использует слишком много таблиц. Допустимо не более 256.
Microsoft OLE DB Provider for SQL Server: Too many table names in the query. The maximum allowable is 256.
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: Error state=1, Severity=F, native=102, line=2215
SQLSrvr: Error state=1, Severity=F, native=106, line=1858
"
лТзПодчиненные=лЗапрос.Выполнить().Выгрузить();
по причине:
Ошибка выполнения запроса "Построенный запрос к СУБД использует слишком много таблиц. Допустимо не более 256.
Microsoft OLE DB Provider for SQL Server: Too many table names in the query. The maximum allowable is 256.
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: Error state=1, Severity=F, native=102, line=2215
SQLSrvr: Error state=1, Severity=F, native=106, line=1858
"
по причине:
Построенный запрос к СУБД использует слишком много таблиц. Допустимо не более 256.
Microsoft OLE DB Provider for SQL Server: Too many table names in the query. The maximum allowable is 256.
HRESULT=80040E14, HRESULT=80040E14, SQLSrvr: Error state=1, Severity=F, native=102, line=2215
SQLSrvr: Error state=1, Severity=F, native=106, line=1858
Спасибо за работу! Обработка интересна скорее с точки зрения разбора графической схемы.
Но вот Ваш код мне разрывает мозг... )))) без обид ;).
Сразу видно что не первый день кодите, но какая же... нехороший человек научил Вас код так набивать? Может быть все таки придерживаться правил и уважать братьев по цеху?
(14) Ну .. Заинтриговал .Я уж ожидал что-нибудь совсем экзотическое.
Не поленился -скачал.
А тут всего лишь нет комментариев и выделения пустыми строками.
"Если" и "цикл" пишутся в одну строку.
Такую причуду я встречал не раз и не у последних программистов.
Очевидно ,им важнее своё удобство , а не что подумает кто-то.
У некоторых эта причуда проходит , у некоторых нет.
Автору : исправьте ошибку при пустом реквизите ДокументСсылка нажатие кнопки "Обновить" вызывает ошибку .
(14) (15) Ну чужой код он всегда плохо читается. Этот стиль принят в нашей команде.
Почему он такой:
Принят максимально линейный код. Т.е.
Если пЭлемент.ТекущийЭлемент=Неопределено Тогда Возврат; КонецЕсли;
И дальше код идет на той же строке без отступа, внимательнее посмотрите, в коде очень мало уровней вложенности. Понятно что если писать так, то нет смысла переносить "возврат" на следующую строку.
Что же по комментариям - я считаю что код должен комментировать себя, у уважаемой фирмы 1с я практически не встречал полезных комментариев, хотя впереди каждой процедуры пишут какую то хрень, которая и так понятна из кода.
Так же в коде соблюдается наш принцип - 1 процедура занимает не более 1 экрана. Что позволяет даже при сложном и компактном коде все таки понять чем же она занимается.
Код сложный, но сложен он тем что 1 строкой он делает гораздо больше чем делает 1 строкой код из типовых конфигураций 1с.
(17) Понятно. Первый язык у специалистов "Кинта" был не 1с .
Термин "причуда" был употреблен с позиции 1с-ника , пишущего для других
1с-ников и ориентирующегося , естественно, на стиль типовых конфигураций 1с.
Префиксы "м","л","п" - определяющие характер переменных, процедур и функций - следует однозначно поддержать . В типовых конфигурациях разбираться в больших процедурах неудобно без этих префиксов тяжело.
Нормальный, довольно качественно оформленный код.
Кучу мелких и понятнейших методов - это здорово, я сам так пишу.
Единственная претензия все-таки к однострочному
Если Условие Тогда Возврат Результат; КонецЕсли
ИМХО в данном случае все-таки важно, чтобы четко было видно, что выполняется граничное условие и какая выполняется обработка для этого случая, развернутый вариант все-таки поудобнее читать и сопровождать.
(18) >> Единственная претензия все-таки к однострочному
Если Условие Тогда Возврат Результат; КонецЕсли
На самом деле это очень удобно (имхо), к тому же уменьшает размер процедуры, что позволяет видеть на экране всю процедуру. (все конечно имхо, но когда к такому привыкаешь отказаться от подобного стиля уже невозможно)
Я много кода перелопатил за свою жизнь от разных программистов и с разным стилем и на разных языках программирования.... и к слову сказать код от 1С намного читабелен, чем Ваш.
1. Для меня длинные строки не удобны для чтения, так как у меня не только код на экране...
2. Код без пробелов и разделителей сливается в одну кашицу... и хоть она и влезает на 1 страницу, но е
(24) (25)
Ну все же наверное нужно сказать что не весь код более читабельный, некоторые особо перловые процедуры от 1с занимают несколько десятков страниц, это конечно вырожденный случай. Но мне явно проще когда всю или почти всю процедуру я вижу.
1. Да к этому стилю надо привыкать. Тут есть плюсы и минусы. Я привык к нему за полгода.
2. Согласен. Иногда кстати я выделяю переводом строки особенно важные блоки. Но так как делает программеры в 1с - а они выделяют разделителями все, в этом смысла я не вижу. По сути не выделять ничего разделителями или выделять разделителями все, одно и тоже, только в первом случае процедура умещается на экран а во втором случае надо листать.
3. ИМХО 70 % комментариев там ни о чем. По моему мнению комментарии нужны только тогда когда имена процедур и переменных не смогут сказать о том что происходит в коде, но комментариев нужно избегать.
4. У меня с этим полный порядок. Я пишу со своей строгой логикой, конфигурация http://tunesoft.ru/ полностью поддерживается мной, если бы мне код в ней казался бы нечитабельным (а там его кстати очень много), то я просто не смог бы развивать эту конфгурацию.
й это читабельности не прибавляет...
3. Иногда если бы не было комментариев к строкам в 1С я бы потратил на разбор кода не 1 час а 4 часа...
4. Проведите эксперимент... откройте свой код который писали год назад и ни открывали не разу... интересно насколько он Вам покажеться читабельным
Кстати маленький нюанс для создания уникальных имен для временных файлов можно использовать функцию ПолучитьИмяВременногоФайла(<Расширение>)
P.S. Это все ИМХО если Вашей команде так удобно то не вопрос, я просто высказал личное мнение...
(25) Теперь спор , на мой взгляд, смысла не имеет.
Но стиль оформления программы - не выдумка автора, а стиль , проверенный в других языках , чуть более распространенных в мире , чем 1с.
Вот что нужно учитывать , критикуя автора темы.
Такое именование переменных в двумя префиксами рекомендуется в
некоторых СУБД (FOXPRO), причем рекомендуется давно (задолго до появления 1с 77). У 1с тут ,как обычно, свой подход , не "субэдэшный" .
У меня твердое убеждение , что разработчики еще языка 77 ходили в майках с надписью "Бэйсик forever !" .
(28) Вот тут не могу не согласится...
(29) Каких языках? я видимо не встречался с этими языками,хотя они более распространены чем 1С.... И в каком из языков поощряется отсутствие комментариев, я вообще не знаю...
Есть определенные стандарты для 1С о чем говорилось в (22) всем известные и большинством используемые, их тоже не дураки придумывали
Если каждый будет выдумывать свой стандарт или переносить с других языков, то это сродни диалектам одного языка. По этому часто западный украинец не понимает восточного. Вот что нужно учитывать критикуя критику ;)
(30) Хочется покритиковать критику критики.
Речь шла про FOXPRO , Субд чуть более распространённую чем 1с.
Имелось ввиду только именование переменных с двумя префиксами.
Одностроковый же стиль для написания операторов выбора и цикла
я встречал также в Паскале .
Паскаль тоже распространен чуть более чем 1с.
Что касается отсутствия комментариев - то это плохо в любом языке, что бы ни писал автор темы.
(31) Хочется не критиковать, а найти истину, а в споре она как известно рождается
> Имелось ввиду только именование переменных с двумя префиксами.
1C вообще то, по моему, рекомендует наиболее полно писать наименование переменных (то есть не тз..., а ТаблицаЗначений...) другое дело кому то лень писать так (а кто то не считает нужным, потому что вроде и так понятно)...
> Одностроковый же стиль для написания операторов выбора и цикла
я встречал также в Паскале
Ну я встречал одностроковый стиль для написания операторов выбора и цикла и в 1С ;)... но код на паскале который я видел (признаюсь видел я его не много), что то не запомнился мне этой особенностью....
P.S. Скорей бы вымер уже FOXPRO, а то я уже устал с ним бороться.... ИМХО...
(31) Комментарии у меня есть, только очень мало. В этой обработке почему то совсем нет, но это скорее исключение. Если посмотреть на названия идентификаторов, то можно заметить что они очень длинные.
(32) Вымрет то он может и вымрет, а вот стиль останется, я например никогда и не писал на фоксе (лабы в универе не в счет)
(33) Рекомендация именовать переменные с двумя префиксами впервые мне встретилась лет 10 назад в литературе по FOXPRO. Но подозреваю , что такой стиль возник еще раньше и в других средах разработки.
(33) (35) (27)п.3
Собсно по поводу комментов к процедурам/функциям... есть у 1С-негоф ИМХО очень замечательная вещь - описание параметров, независимо от того понятны они или нет:
// Проверяет наличие требуемых данных в источнике и Формирует таблицу значений
//
// Параметры
// Источник – ТаблицаЗначений или ТабличнаяЧасть или КоллекцияСтрокДереваЗначений с исходными данными
//
// Реквизиты – структура – Структура реквизитов.
// Ключ - Наименование колонки в источнике
// Значение - Наименование колонки в получаемой ТЗ, если значение опущено - приравнивается ключу.
// ПолучитьНомерСтрокиДокумента - булево
// Используется только при выгрузке из табличной части документа.
// В формируемой таблице создает новую колонку "НомерСтрокиДокумента"
// и заполняет её реальными номерами строк
//
// КоллекцияКолонокДереваЗначений - только для коллекции строк дерева значений.
//
// Возвращаемое значение:
// Таблица значений или Неопределено (если не хватает реквизитов)
//
Функция СформироватьТаблицуЗначений(Источник,Реквизиты=Неопределено,ПолучитьНомерСтрокиДокумента = ложь,ФормироватьОтстутствующиеКолонки=Ложь,КоллекцияКолонокДереваЗначений=Неопределено) экспорт
Показать
Имея такие комменты перед процедурой/функцией намного легче писать вызовы... не надо лопатить код (хоть он и умещается на 1 странице). Ну и естественно ежели оно тебе не надо - в свернутом виде занимает 1 строку...
1. Главный принцип хорошего кода - легкость его чтения, а значит, и сопровождения и т.д.
В связи с этим принципом можно придумывать себе стиль с одним, двумя префиксами и т.д.
2. Поэтому лично я редко пишу комменты, лучше юзать правильные имена методов и переменных, не бояться править код, чаще использовать тестирование.
В целом из примера мало что понятно. Необходимо разбираться долго. Для применения необходимо понимание основ работы с графом. На текущий момент материалов по построению своих схем с помощью кода не нашел. Если уважаемый автор сделает статью, в которой опишет основы (с подробными примерами кодов) работы с графом - это будет просто незаменимый материал.
(44) Это важно, в первую очередь, для стрелок.
Ибо когда граф получился на 3 страницы - офигенно весело сролиться вверх-вниз, пытаясь не потерять линию. :)
w-divin пишет:
Собсно по поводу комментов к процедурам/функциям... есть у 1С-негоф ИМХО очень замечательная вещь - описание параметров, независимо от того понятны они или нет:
Да бывают комментарии и полезные, в любом правиле есть исключения.
Стрелки переделаю. По поводу скорости посмотрю, переделаю.
Благодарю. Сомневаюсь, что юзерам понадобится граф именно для этой цели но "Обработка может быть использована как пример того как формировать программно Графическую схему." - как раз очень гуд
Бывают дубли линий. Не разбирался. Просто в процедуре мОбновитьОтчет() перед вызовом мПостроитьСхемуПоСвязям() добавил вызов процедуры:
Процедура УдалитьПовторяющиесяСтроки()
УжеВТЧ = Новый Соответствие;
КолвоСтрокТЧ = СвязьДокументов.Количество();
Для ОбратныйИндекс = 1 По КолвоСтрокТЧ Цикл
СтрокаТЧ = СвязьДокументов[КолвоСтрокТЧ - ОбратныйИндекс];
Если УжеВТЧ[СтрокаТЧ.Документ] = СтрокаТЧ.ДокументСвязанный Тогда
СвязьДокументов.Удалить(КолвоСтрокТЧ - ОбратныйИндекс);
Иначе
УжеВТЧ[СтрокаТЧ.Документ] = СтрокаТЧ.ДокументСвязанный;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Иногда граф получается слишком большим. Неплохо бы добавить возможность исключения документов. Самый простой вид фильтра, например, если смотрим связи документа ПоступлениеТоваровУслуг, добавить флажок "кроме других документов ПоступлениеТоваровУслуг". Можно, конечно, реализовать процедурой, аналогичной вышеприведенной, можно и немного покопаться для увеличения быстродействия.
"Управление торговлей и взаимоотношениями с клиентами (CRM)", редакция 1.0 (1.0.2.2)
Обработка не хотела работать с задачами и бизнес процессами. Сказал чтобы пропускала их. Начала строить дерево, но ничего не построила. Работала примерно два часа и упала :-(
Жаль. Попробовать не удалось. Идея хорошая.
Функция РазобратьПутьКОбъектуМетаданных(ПутьКДанным,мКэшПраваДоступаКМетаданным,МетаданныеДокументы) Экспорт
Структура = Новый Структура;
СоответствиеИмен = Новый Массив();
СоответствиеИмен.Добавить("ТипОбъекта");
СоответствиеИмен.Добавить("ВидОбъекта");
СоответствиеИмен.Добавить("ПутьКДанным");
СоответствиеИмен.Добавить("ИмяТаблЧасти");
СоответствиеИмен.Добавить("ИмяРеквизита");
Чуть позже сам вставлю ее в обработку. Надо бы отвязываться от стандарта. Да в конфигурации все равно должен быть критерий отбора для перебора подчиненных документов, с именами: СвязанныеДокументы или СтруктураПодчиненности
ошибка вываливается при формировании запроса в функции
мПолучитьМассивДокументовПоКритериюОтбора()
когда лТекстЗапроса = "".
нужно проверять текст запроса перед его выполнением.
Довольно хорошая разработка на первый взгляд ИМХО, правда под себя все же пришлось капельку доработать.
Убрал возможность редактировать схему, убил ссылку внизу окна, добавив на ее место панель с кнопкой закрыть, немного по перемещал выравнивающие линии, потом переименовал реквизит "ДокументСсылка" в "СсылкаНаОбъект" и добавил в модуле обработки следующую процедурку:
Функция Печать() Экспорт
ПолучитьФорму("Форма").Открыть();
Возврат Неопределено;
КонецФункции // Печать
Получилась таки еще и внешняя печатная форма. Вот только думаю приклепать или нет авторегистрацию ко всем документам конфигурации как это делается в альтернативном решении http://infostart.ru/public/103500/
Не работает в типовой БП 2.0 8.2:
{Форма.ФормаО.Форма(328)}: Ошибка при вызове метода контекста (ЗначениеИзФайла)
лНастройкиТипы = ЗначениеИзФайла(КаталогВременныхФайлов() + "СтруктураПодчиненностиНастройкиТипы");
по причине:
Ошибка преобразования
Столько всего про код написано, что скачал специально посмотреть код. =)
Мне, как фанату Макконела, код во многом нравится. Небольшие цельные методы, самодокументируемые имена, все класс.
Сбивают с толку префиксы. Вот эти "п-л-м". Где-то я, вроде, читал что об эти префиксы много копий поломали в свое время и решили не использовать во многих случаях в других языках. Ну, то не вспомню уже где.
И еще не хватает более общей структуры. Не зря же есть рекомендованная "структура модуля". Можно было бы как-то выделить блоками - это вспомогательные, это основная логика, это отрисовка.
Для чего используются префиксы. Самое основное чтобы не спутаться в том где определена переменная и не определить ее дважды. Часто ошибки бывают что определил на форме, потом ту же переменную в модули и лезут ошибки, самое плохое не ясно какие это ошибки.
А вообще я считаю что хорошего программиста определяет то как он пишет и то как четко он следует своим принципам.
Можно кстати по структуре модуля? Что за рекомендованная?
Хм. Мысль хорошая. Надо будет построить с помощью graphwiz-а и этой программы www.схемы1С.рф интерактивные графы.
Построю DOT файл по структуре подчиненности, скормлю graphwiz-у, проанализирую результат, переведу его в xml файл понятный для ОптимаСофт:Схемы и получу интерактивный граф.
При реализации своей задачи по отрисовке схемы столкнулся с проблемой, когда связи выводятся не совсем красиво, если нажимать стандартную кнопку перерисовки линии в контекстном меню, то все отлично. Вопрос: как вызвать программно эту кнопку для каждой линии? может кто сталкивался?
Данный пример не работает в управляемых формах. Пытаюсь выводить идентичные структуры в УФ и обычных, в обычных выводит в УФ при попытке выполнить метод Прочитать() пишет "Ошибка формата потока"
Я скачал бесплатную версию, запустил, у меня что-то глюкнуло в базе и пропали все пункты меню. Остались только правка и окна. Выгрузка/загрузка не помогли (в т.ч. восстановление на другом компе). помогает только удаление всех юзеров. Стоит добавить одного - меню исчезает. Я не утверждаю, что глюк связан с обработкой, но возник он сразу после ее открытия....